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ers interconnected by a computer network. The system 
includes an arbiter computer and a plurality of conversation 
computers interconnected by a computer network. The arbi- 
ter computer creates a public key pair comprising a new 
public key and a new private key, and causes the new public 
key to be transmitted to the conversation computers. The 
conversation computers receive the public key and transmit 
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at least some of the conversation computers during a con- 
versation among the conversation computers, and to store 
the encrypted messages in a message log. The conversation 
computers cause messages in the message log to be 
decrypted using the new public key. 
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ENABLING BUSINESS TRANSACTIONS IN and the new private key, and can decrypt messages using the 

COMPUTER NETWORKS new private key as evidence that the conversation computer 

has obtained the authorization certificate legitimately. 

REFERENCE TO APPENDIX Numerous other fcamres, objects, and advantages of the 

. ^ . J- A ■ u • u ^ -.u ♦u- 1- ^ invention will become apparent from the following detailed 
A text Appendix A is bemg submitted with this appbca- , . . . « 

^ '^'^ description when read m connection with the accompanying 



drawings. 

BACKGROUND OF THE INVENTION g^j^p DESCRIPTION OF THE DRAWINGS 



'llie present invention relates in general to enabling busi- 10 ^ ^ ^ ^. ^ ^^^^^^ certifying authoriza- 

ness transactions in computer networks. ^.^^^ 

Certifying authorities are known that generate public key pj^g 2A and 2B are a flow chart illustrating the operation 

certificates, enciphered with the private key of the certifymg ^^^^ system of FIG 1 

authority, that serve as letters of introduction of a particular ^^^^ I • r r i a r 
party to any other party that can recognize the certifying 15 MG. 3 is a diagram of a system for creatmg a log A of a 

authority as an introducer. The certifying authority typically conversation. 

makes the party seeking the certificate of introduction to FIG. 4 is a flow chart illustrating the operation of the 

prove that it is who it says it is, and then the certifying system of FIG. 3. 

authority accepts the public key of the party and returns it in FIG. 5 is a diagram of a system for certifying an autho- 

the certificate of introduction encrypted in the private key of rizalion of a doing-business-as entity to perform business- 

the certifying authority, thereby binding the name of the related transactions. 

particular party to the public key of the party. pjQ 6 is a flow chart Olustrating the operation of the 



SUMMARY OF THE INVENTION 



system of FIG. 5. 
25 DETAILED DESCRIPTION 



One aspect of the invention features a system for creating 

a log of a conversation, the system including an arbiter With reference to FIG. 1, a system for implementing a 

computer and a plurality of conversation computers inter- transaction in accordance with the present invention 

connected by a computer network. The arbiter computer includes an authorizing computer 10, a smart card 12 at 

creates a public key pair comprising a new public key and authorizing computer 10 that corresponds to a specific user 

a new private key, and causes the new public key to be of the authorizing computer 10, an authorized computer 14 

transmitted to the conversation computers. The conversation that is authorized by authorizing computer 10 to perform 

computers receive the public key and transmit messages some specific action, and a transaction computer 16 that 

during the conversation. The arbiter computer uses the new performs a transaction with authorized computer 14 that 

private key to encrypt messages transmitted by at least some 35 includes the authorized computer 14 performing the autho- 

of the conversation computers during a conversation among rized action. The system also includes a certifying authority 

the conversation computers, and to store the encrypted 18 that performs the conventional function of certif>ing the 

messages in a message log. The conversation computers identity of the user to authorized computer 14 and transac- 

cause messages in the message log to be decrypted using the tion computer 16. 

new public key. 40 The smart card 12 at authorizing computer 10 is initial- 

Bccause the arbiter computer creates a new public key izcd once by the creation of a public key pair for the smart 

pair and uses the private key to encrypt the messages stored card (a private key that never leaves the smart card and a 

in the message log, the arbiter computer can lock the public key that can be distributed to others) and a public key 

message log by destroying the private key. Messages can be pair for the user of the card (a private key that the user keeps 

read from the message log by any party having the public 45 confidential and a public key that can be distributed to 

key. but the contents of the message log cannot be altered. others). The public key pair for the user of the card can be 

Another aspect of the invention features a system for created by the manufacturer of the smart card (this guaran- 

certifying an authorization of a doing-business-as entity to tees uniqueness of the public key pair, provided that the 

perform business-related transactions, the system including manufacmrer of the smart card can be trusted) or can be 

a convener computer and a plurality of conversation com- 50 downloaded to the smart card from another source. 

puters interconnected by a computer network. The convener With reference to FIGS. 2A and 2B, in a general imple- 

computer receives a plurality of authorization certificates mentation of the present invention, the authorizing computer 

certifying authority of users of corresponding ones of the sends the authorized computer a public key certificate iden- 

conversation computers to perform business- related trans- tifying the user and the user's public key to (step 20), as is 

actions referred to in the authorization certificate. The con- 55 conventional. The identification certificate is signed with the 

vener computer creates a public key pair that includes a new private key of the certifying authority, and the authorized 

public key and a new private key, and creates an introduction computer verifies the authenticity of the signanire on the 

certificate that certifies that a holder of the introduction identification certificate using the public key of the ccrtify- 

ccrtificate is a doing-busincss-as entity authorized to per- ing authority, which certifying authority is known and 

form business-related transactions refened to in the intro- 60 trusted by the authorized computer (step 22). Similarly, the 

duction certificate that are derived from the business-related authorized computer sends a public key certificate to the 

transactions referred to in the authorization certificates authorizing computer identifying the user of the authorized 

received by the convener computer. The introduction cer- computer and the user's public key (step 24), and the 

tificate includes the new public key. The convener computer authorizing computer verifies the authenticity of the signa- 

causes the introduction certificate and the new private key to 65 ture on the identification certificate using the public key of 

be transmitted to the conversation computers. Each of the the certifying authority (step 26) (this may or may not be the 

conversation computers receives the introduction certificate same certifying authority that issued the identification cer- 



05/28/2004, EAST Version: 1.4.1 



us 6,192,131 Bl 



4 



10 



15 
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tificate for the user of the authorizing computer). Again, this 
is as in conveatioaal practice. 

The authorizing conoputer also creates an identification 
certificate for the smart card at the authorizing computer and 
sends it to the authorized computer signed with the private 
key of the user of the smart card (step 27), and the authorized 
computer verifies the authenlicily of the signature on the 
identification certificate (step 28) using the public key of the 
user of the smart card at the authorizing computer, which 
was received by the authorized computer in step 20. 

The private key of the identification certificate for the user 
of the smart card will be used for encryption (sealing) 
purposes and the private key of the identification certificate 
for the smart card itself will be used for signing purposes. In 
alternative embodiments it is possible to switch the roles of 
these private keys, however. 

The authorizing computer encrypts the private key of the 
user of the smart card with the public key of the smart card, 
and encrypts the private key of the smart card with the public 
key of the user of the smart card, and sends both encrypted 
private keys to an escrow agent (step 29). ITiis ensures that 
if one private key is lost, the other private key can be 
retrieved from the escrow agent. 

The smart card in the authorizing computer then generates 
an authorization certificate that certifies that the authorized 
computer is authorized to take some action specified in the 25 
authorization certificate (step 30). The authorization certifi- 
cate contains a description of the authorized action and a 
public key of a newly minted public key pair corresponding 
to the authorized action. In essence, the authorization cer- 
tificate represents a synthetic public identity that corre- 30 
sponds to the authorized action, and smart card 28 functions 
as a miniature certifying authority that both creates and 
certifies the synthetic public identity. The smart card 28 
signs the authorization certificate with the private key of the 
smart card 28 (step 31) and encrypts the newly minted 
private key with the public key of a smart card at the 
authorized computer (step 32). The authorizing computer 
then sends the authorization certificate and the newly minted 
private key to the authorized computer (step 33). The 
authorized computer verifies the signature on the authoriza- 
tion certificate using the public key of the user of the smart 
card (step 34), which proves to the authorized computer that 
the authorization certificate was generated by the smart card, 
and the authorized computer then presents the authorization 
certificate to the transaction computer (step 36) as proof that 
the authorized computer is authorized to perform the action 
specified in the authorization certificate. The transaction 
computer decrypts the authorization certificate using the 
public key of the smart card at the authorizing computer 
(step 38), which proves to the transaction computer that the 
authorization certificate was generated by the smart card, 
and then the transaction computer reads the description of 
the authorized action (step 40). If the transaction computer 
requires verification of the authorization of the authorized 
computer to perform the action, then the transaction com- 
puter sends the authorized computer a message encrypted 
with the newly minted public key (step 42), and the autho- 
rized computer decrypts the message using the newly minted 
private key (step 44) and sends a response to the transaction 
computer proving that the authorized computer has read the 
message (step 46). The transaction computer then performs 
a transaction with the authorized computer in which the 
authorized computer performs the authorized action (step 
48). This transaction can occur while the authorizing com- 
puter is off-line. 

In one specific example of the method of FIGS. 2A and 
2B, the authorized computer is operated by an electronic 



35 



45 



50 



55 



60 



65 



merchant and the authorizing computer is operated by a 
customer. The customer provides an identification certificate 
to the electronic merchant, who verifies it with the certifying 
authority that issued the certificate, as described above. This 
authenticates the customer to the electronic merchant. 
Similarly, the electronic merchant provides an identification 
certificate to the customer, who verifies it with the certifying 
authority. This authenticates the electronic merchant to the 
customer. The customer then provides to the electronic 
merchant an authorization certificate, signed by the smart 
card at the customer*s computer, containing a purchase 
order, an authorization to debit the customer's account at a 
financial institution, and a newly minted public key, and the 
customer also provides to the electronic merchant the newly 
minted private key of the public key pair. The newly minted 
private key may be escrowed outside of the system herein 
described. The electronic merchant presents the authoriza- 
tion certificate to the financial institution, which verifies the 
signature on the authorization certificate using the custom- 
er's public key and uses the newly minted public key 
contained in the authorization certificate to encrypt a mes- 
sage to the electronic merchant, which uses the newly 
minted private key to open the message and send a response 
to the financial institution proving that the electronic mer- 
chant has read the message sent by the financial institution. 

The financial institution then debits the customer's 
account and notifies the electronic merchant that the account 
has been debited. One advantage of this procedure is that the 
entire transaction between the financial institution and the 
electronic merchant can occur while the customer is ofif-line. 

Background information on computer networks for elec- 
tronic sales and payment transactions can be found in U.S. 
patent application Sen No. 08/168,519, filed Dec. 16, 1993 
and U.S. patent application Ser. No. 08/328,133, filed Oct. 
24, 1994, the entire disclosures of which are hereby incor- 
porated herein by reference. 

If the item purchased by the customer is delivered elec- 
tronically to the customer by the electronic merchant, the 
electronic merchant may package the purchased item with 
the authorization certificate created by the customer. The 
customer can then check the certificate without consulting 
an on-line certifying authority, because the certifying author- 
ity is the customer itself. 

Alternatively, the customer may furnish two different 
authorization certificates to the electronic merchant: one for 
the reflexive information delivery back to the customer and 
one for the electronic merchant to use when invoicing the 
customer through the financial institution. 

The item purchased by the customer may be software 
leased by the customer. The customer may rely on the 
authorization certificate returned by the electronic merchant 
to ensure that it is the electronic merchant of choice that is 
transmitting the software. The electronic merchant may 
tailor the software so that it can run only on a platform in 
which the newly minted private key of the authorization 
certificate is provably present, in order to prevent the soft- 
ware from being duplicated and used by others (at least 
insofar as it is in the customer's self-interest to prevent 
replication of the private key and thereby to prevent repli- 
cation of the authority represented by the private key). 

Each authorization certificate in accordance with the 
present invention specifies membership in a "club" that 
confers certain rights. Smart card owners would have the 
ability to cx)nfer membership privileges to other smart card 
owners, who would accumulate these membership privi- 
leges as authorization certificates stored in their smart cards. 
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Because the authorization certificate carries a permission 
or authorization to perform a particular action rather than 
just an authentication of a person's identity, the authoriza- 
tion relationships arc inverted with respect to the conven- 
tional practice in connection with conventional public key 
identification certificates. In particular, with conventional 
identification certificates the recipient of the certificate, after 
satisfying itself of the certificate's validity, authorizes the 
performance of a certain action, but with the authorization 
certificates of the present invention it is the authorizing 
computer that transmits the certificate that authorizes the 
performance of a certain action. 

Although we focus herein primarily on the use of smart 
cards to generate authorization certificates, such certificates 
can be generated by other types of smart tokens. As used 
herein, the term "smart token" refers to a cryptographic 
token that communicates with a computer and contains a 
private key half of a private key pair corresponding to the 
user of the smart token. Examples of smart tokens include 
credit-card sized cards having an embedded microprocessor 
that are insertable into a reader on the authorizing computer, 
and other smart tokens such as PC/MCIA cards. 

The certificate minted by the smart card at the authorizing 
computer is a file structure having a set of "criticals" and a 
set of "extensions." The "criticals" include a distinguished 
name (conventionally, the user's name, but more generally 
simply a unique name), the name of the issuer of the 
certificate (the user's smart card), the cryptographic algo- 
rithm used to generate the newly minted public key pair, the 
key length, the signature algorithm used to hash the data in 
the certificate to ensure that the data is not altered, the 
signature itself, the lifetime of the certificate (the period 
during which the authorized action remains authorized), the 
newly minted public key, the serial number of the certificate, 
and all the serial numbers in the "chain" of certificates 
(beginning with a top-level certificate issued by a top-level 
certifying authority that certifies the identity and public key 
of a second-level certifying authority that issues a second- 
level certificate, etc.). 'ITie "extensions" include the descrip- 
tion of the authorized action. A detailed discussion of the 
format of certificates is provided as Appendix A. 

In certain embodiments some of the "extensions" that are 
unique to the authorization transactions described herein 
may be arbitrarily marked as "critical" so that any computer 
that receives the certificate will refuse to process the cer- 
tificate if it is not programmed to process the extensions that 
are marked "critical" in accordance with the techniques of 
the present invention. This scheme of arbitrarily marking 
certain extensions, such as the name of a product being 
purchased or the lifetime of the product being purchased, as 
"critical" helps to ensure that the authorization certificate 
will not be useful to people who manage to copy it. 

Public key certificates are revoked when they appear on a 
"certificate revocation list" issued by the certifying authority 
identifying the serial numbers of revoked certificates corre- 
sponding to compromised or stolen smart cards. When a 
computer receives a public key certificate it may check the 
certificate revocation list created by the certifying authority 
(or its designee) to determine whether the serial number of 
the public key certificate is on the certificate revocation list. 

There is typically no need to maiiitain certificate revoca- 
tion lists for the authorization certificates according to the 
present invention, however, because revocation can be 
accomplished simply by notifying the recipient of the autho- 
rization certificate or by waiting for the lifetime of the 
authorization as specified in the authorization certificate to 
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expire. In other words, because the synthetic identity created 
by the smart card is an authorization rather than an actual 
identity of a user, the synthetic identity is so limited in scope 
that revocation can be made unnecessary. 
5 Referring again to FIG. 1, certain embodiments of the 
invention do not require a transaction computer 16. Rather, 
authorizing computer 10 sends the authorization certificate 
to a smart card at authorized computer 14 that interacts with 
a program stored at the authorized computer. For example, 
10 authorized computer 14 might contain a program that 
requires a license or program fragment to function, the 
license or program fragment being contained in the exten- 
sions of the authorization certificate, which is stored in the 
smart card at authorized computer 14. The program may 
15 interact with the smart card in a manner analogous to the 
sequence of steps 42-46 in FIG. 2B to ensure that the smart 
card has obtained the conversation certificate and program 
fragment in a legitimate manner (program causes message to 
be sent to smart card encrypted with newly minted public 
20 key; smart card decrypts message with newly minted private 
key; smart card sends response proving that smart card has 
read the message). The authorization certificate containing 
the program fragment may be encrypted not only with the 
newly minted public key, but also with the public key of the 
25 smart card at the authorized computer, so that the buyer can 
receive the authorization certificate but can process the 
fragment only if that particular smart card is present. 

Additional specific implementations of authorization cer- 
tificates of the type described above are as follows: 

30 

While a consumer is at work, the consumer uses a smart 
card to buy a video from a Web page to be downloaded. The 
smart card issues an authorization certificate to the down- 
load server corresponding to the Web page. The server calls 
the consumer' s-home-PC modem and presents the authori- 
zation certificate as a "May I download?" request. The 
consumer's home PC uses the public key of the consumer's 
smart card to validate the authorization certificate, and 
permits the download. When the consumer returns home, the 
video is ready to be watched. 

A consumer uses a smart card to subscribe to an on-line 
magazine, but the magazine doesn't appear on a Web site 
(because the Web is slow) and it doesn't appear in the 
consumer's mailbox (because the magazine is too bulky for 
45 e-mail). Rather, the consumer sends an authorization cer- 
tificate to the magazine publisher to send the magazine to the 
consumer's local disk, or on the consumer's home directory. 
The consumer's computer accepts the magazine's asynchro- 
nous download because the publisher presents the authori- 
50 zation certificate issued by the consumer's smart card when 
the consumer subscribed. The magazine spontaneously 
appears on the local disk or home directory, and the con- 
sumer receives a brief e-mail notice of each magazine's 
arrival. As has been described previously, the publisher may, 
55 at its discretion, have encrypted the magazine such that it 
may only be read when the customer's smart card is present. 

A purchasing oflHcer needs to buy something that requires 
a countersignature. The purchasing officer generates a new 
public key pair and sends an authorization certificate (to be 
60 sent eventually to a merchant) and the new private key 
(sealed) to a higher-vunking ofiScer. The higher-ranking 
oflBcer mints another ?.:ijvhorization certificate containing the 
authorization certificats generated by the purchasing officer 
as well as authoriza'.ions granted by the higher-ranking 
65 oCBcer The authorizal:oas granted by the higher-ranking 
olEcer include an authori'.alion for the purchasing oflicer to 
buy the item requiring countersignature, and perhaps a 
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limitation for the particular purpose at hand for which the 
item is being purchased. The authorization certificate cre- 
ated by the higher-ranking oflBcer is sent to the purchasing 
officer along with the newly minted private key correspond- 
ing to the authorization certificate minted by the higher- 
ranking officer. This authorization certificate may be 
encrypted in the public key of the higher-ranking officer's 
smart card so that this authorization certfficate is usable only 
after a session in which the higher-ranking officer's smart 
card has been used. The new private key is sealed in the 
junior officer's public key and may also be sealed in the 
public key of the junior officer's smart card in order to deny 
the junior officer the opportunity for further delegation. This 
scenario, in which the senior officer generates the new public 
key pair, is inherently consistent with escrow principles. The 
junior officer can use the authorization certificate generated 
by the senior officer in a transaction to which the junior 
officer would not otherwise be entitled to take part. The 
senior officer can inspect any and all communications made 
under cover of the delegated authority. This scheme can be 
extended to multiple counter-signatures including those 
which must be ordered in a particular way, because each 
successive authorization certificate includes a copy of the 
previous authorization certificate; i.e., the authorization cer- 
tificates are recursive. In alternative embodiments, each 
successive authorization certificate includes only the serial 
number of the previous authorization certificate or includes 
only a description of the authorizations contained in the 
previous authorization certificate. 

An executive wishes to delegate to a subordinate the right 
to process the executive's e-mail while the executive is on 
vacation. The executive issues an authorization certificate 
for processing the executive's mail, with limited time valid- 
ity. Because the authorization certificate is a delegation 
certificate, any cryptographically signed mail sent by the 
subordinate will be signed with the newly minted private 
key "on behalf of* the executive. Recipients of such e-mail 
messages also receive the authorization certificate that estab- 
lishes the subordinate's right to send e-mail on behalf of the 
executive. 

An investor issues an authorization certificate to a broker 
combining a "limit order" and a "trade at close" directive, 
i.e., an order to trade at a range of prices if those prices 
obtain near a market's closing moment. Such an authoriza- 
tion certificate satisfies all the ordinary requirements of a 
secure communication: it is vcrifiably authentic, 
authoritative, non-repudiable, and can be structured to 
require it to be confirmed by the recipient at the moment of 
use (thereby enabling the authorization to be revoked if 
necessary). Members of a stock exchange can issue autho- 
rization certificates that enables investors to book trade 
orders directly through to the floor of the slock exchange, the 
authorization certificates containing volume or credit limits 
corresponding to the assumed risk of trade delegation to the 
investor. 

A consumer writes an authorization certificate instead of 
a paper check. The authorization certificate authorizes the 
consumer's bank to debit the consumer's checking account 
upon presentation of the authorization certificate to the bank 
by a named or un-named identity. The consumer can send a 
"stop payment" order to the bank by sending a notice of 
certificate revocation to the bank signed with the consumer's 
private key. 

A consumer uses a "personal-proxy web-server" such as 
Open Market's OM-Express™ to download a catalog, does 
off-line shopping, and places the order whenever it is 
convenient to do so by uploading a collection of "purchase" 
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authorization certificates to the publisher of the catalog. The 
publisher presents the authorization certificates to the con- 
sumer's bank to debit the consumer's account at the bank. 
Referring to FIG. 3, one particular type of a authorization 
5 certificate is a conversation certificate that is created by an 
arbiter computer 50 of a conversation among a set of 
computers 52. As shown in the block diagram of FIG. 4, at 
the beginning of the conversation each computer participat- 
ing in the conversation sends to the arbiter a public key 
certificate, issued by a certifying authority, that identifies the 
user of the computer and the user's public key (step 54). The 
arbiter verifies the authenticity of the identification certifi- 
cate by decrypting it with the public key of the certifying 
authority, which certifying authority is known and trusted by 
^5 the authorized computer (step 56). 

The arbiter next generates a conversation certificate (step 
58) that includes the public key of a newly minted public key 
pair and that also includes a pointer to a database containing 
a message log, and the arbiter distributes the conversation 
20 certificate to each of the computers in the conversation, 
encrypted with the respective public keys of each user of the 
computers in the conversation (step 60). The new private 
key is not distributed, however. The arbiter listens in to the 
conversation, encrypts each message transmitted from one 
25 computer to another using the newly minted private key, and 
records the messages in the message log (step 62), In fact, 
all messages may pass through the arbiter, i.e., each message 
is sent to the arbiter for encryption and recording and the 
party to whom the message is sent uses the new public key 
3Q to decrypt the messages as they are recorded in the message 
log. At the end of the conversation, one of the computers 
notifies the arbiter that the conversation is finished (step 64), 
and the arbiter records a "done" notice in the message log, 
encrypted with the new private key (step 66). After a 
35 predetermined period of time has elapsed, the arbiter 
destroys the private key (step 68). This makes it impossible 
to alter the log entry; yet the users to whom the conversation 
certificate was distributed may read the message log by 
decrypting the messages using the new public key contained 
40 in the conversation certificate (step 70). 

In the event that there are multiple conversations between 
multiple subsets of the computers monitored by the arbiter, 
the arbiter can create a set of conversation certificates 
corresponding to each of the respective conversations. For 
45 example, if initially there is a conversation between two of 
the computers and then three additional computers join in, 
the arbiter can initially create a conversation certificate for 
the two computers, which it distribules-to the two computers 
only, and then when the arbiter is notified that three addi- 
50 tional computers will be joining, the arbiter creates a new 
conversation certificate and distributes it to all five comput- 
ers. The arbiter records, as the final entry in the message log 
for the first conversation, a link to the message log for the 
second conversation, encrypted with the private key for the 
55 first conversation, which the arbiter then destroys. The 
arbiter records, as the first entry in the message log for the 
second conversation, a link to the message log for the first 
conversation, encrypted with the private key for the second 
conversation. The two parties to the first conversation can 
60 read the first message log by decrypting the messages using 
the public key contained in the first certificate, and all five 
parties can read the second message log by decrypting the 
messages using the public key contained in the second 
certificate. 

65 With reference to FIG. 5, one particular system that 
implements conversation certificates and other authorization 
certificates includes a convener computer 72 that convenes 
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a business meeting and a set of computers 74 operated by 
parties to the business deal. The business meeting may 
pertain to an exchange of stocks or other instruments on a 
slock exchange, an exchange of commodities on a 
commodities, exchange, an auction, etc. In the case of an 
exchange of instruments on a stock exchange, convener 72 
may be operated by the stock exchange itself. The system 
includes at least one certifying authority computer 76, 
operated by an investment banking firm, that certifies to 
convener 72 the authority a given party brings to the 
business deal (such as the shares controlled by the party, the 
right of the party to access certain files that might contain 
credit card numbers or privileged information such as per- 
sonnel data or company secrets, and the right of the party to 
delegate authority). 

The actual parties to the business deal may be the users of 
computers 74, and the business deal involves the creation of 
an ad hoc "doing business as" (DBA) entity corresponding 
to Ihe-entire business group. In another model, there is one 
actual party (the group), and each computer 74 is operated 
by an agent of the actual party and corresponds to a distinct 
DBA entity. Other models involving other combinations of 
actual parties and DBA entities are possible. 

Referring to FIG. 6, in operation of the system of FIG. 5, 
each of the actual parties to the business deal obtains, from 
a certifying authority computer operated by an investment 
banking firm, an authorization certificate and a private key 
of a new public key pair minted by the certifying authority 
computer (step 78). The authorization certificate contains a 
description of the party's authority (shares controlled by the 
party, the right of the party to access certain files, and the 
right of the party to delegate authority to another party in the 
business deal, including DBA entities, or to an outside 
party). The authorization certificate also contains the public 
key of the new pubhc key pair minted by the certifying 
authority computer as well as a hash signature, the time 
period during which the authorization remains valid, a serial 
number of the authorization certificate, etc. The authoriza- 
tion certificate is created by the certifying authority com- 
puter and used by the parties to the business deal in the 
manner described above in connection with FIGS. 1 and 2. 

Each of the actual parties to the business deal presents to 
the convener a certificate request that asks the convener to 
issue one or more introduction certificates corresponding to 
one or more respective "doing business as*' (DBA) entities 
(step 80). Each certificate request also includes the identities 
of the actual parlies to ihe business deal, the authorization 
certificate of the actual party submitting the request, and a 
business model (described in detail below) that specifies 
how much information the convener should record in a 
message log during the business negotiations and who 
should be granted access to the recorded information. The 
certificate requests of the actual parties should all specify the 
same DBA entity or entities and the same actual parties. 

The convener uses the public key of the certifying author- 
ity computer or computers to open the authorization certifi- 
cates contained in the certificate requests (step 82), checks 
the hash signature in the authorization certificate to ensure 
against tampering, checks the time period in the authoriza- 
tion certificate to ensure that the authorization remains valid, 
and checks the serial number of the authorization certificate 
to ensure it has not been revoked (step 83). The convener 
uses the new public keys minted by the certifying authority 
computer or computers to encrypt messages to the actual 
parties to the business deal (step 84), which the actual parties 
decrypt using the new private keys minted by the certifying 
authority computer or computers (step 86). The actual 
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parlies then send responses to the convener proving that the 
parties have decrypted the messages sent by the convener 
(step 88). This proves to the convener that each of the actual 
parties has obtained its authorization certificate legitimately. 
5 Alternatively, the convener simply sends a message to the 
certifying authority computer inquiring whether the autho- 
rization certificate is accurate (step 90) and receives a 
response from the certifying authority computer (step 92). 
The convener issues a conversation certificate and broad - 
^0 casts it securely to each computer involved in the business 
deal (step 94), The conversation certificate is created and 
used in the manner described above in connection with 
FIGS. 3 and 4. 

The convener then issues an introduction certificate for 
each DBA and sends that introduction certificate to each of 
the computers involved in the business deal, along with the 
private key of a new public key pair, encrypted in the private 
key of the conversation certificate (step 96). The introduc- 
tion certificate identifies the DBA and its lifetime and 
describes the extent of the authority of the DBA (shares 
controlled by the DBA, the right of the DBA to access 
certain files, and the right of the DBA to delegate authority). 
The extent of the DBA's authority is based on the authority 
of the actual parties, including their authorization to delegate 
their authority to the DBA. The introduction certificate also 
includes the public key of the new public key pair, llie 
parlies to the business deal present the introduction certifi- 
cate to outside parties whenever the parties, acting as or on 
behalf of the DBA entity, submit execution instructions to 
■'^ outside parties for trades of shares on the convener's stock 
exchange or an outside stock exchange. This allows the 
DBA entity to be a full player in the electronic world of 
commerce, just as more stable and permanent players are. 
2^ Because the introduction certificate is based on the autho- 
rization certificates received by the convener, the authority 
of the DBA is traceable to the authorities of the actual parties 
to the business deal, even though no external authority is 
involved in the business deal aside from the passive con- 
^ vener. In short, the introduction certificate and conversation 
certificate together provide anonymity of membership in 
DBAs, yet with recourse to the message log. 

The computers communicate with each other and also 
transmit execution instructions to outside parties (along with 
45 an introduction certificate if the execution instructions arc 
issued by a party acting as or on behalf of a DBA entity) 
based on agreements reached during the business negotia- 
tions (step 98). The convener records, in a message log 
corresponding to the conversation certificate, the execution 
5Q instructions transmitted to outside parties and, depending on 
the "business model" that the parties to the business deal are 
following, the messages transmitted between computers 
involved in the business deal, in the same manner described 
above in connection with FIGS. 3 and 4 (step 100). Each 
55 message sent to the convener for encryption and recording 
is decrypted by the party to whom the message is sent using 
the new public key. As conversation progresses, various 
parties may choose to super-encrypt their messages in whole 
or in part between all or only a subset of the participants, 
go using a single private key From the convener's point of 
view, this is immaterial even though the records it keep may 
be opaque to the convener due to the super-encryption, and 
all such conversation will be logged. 

According to a "reflexive club" business model, the 
65 parties trust each other and do not require the convener to 
record the messages between the computers involved in the 
business deal. All of the execution instructions to outside 
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parties are recorded, however. According to a "reflexive club to external parties such as specialists on the trading floor of 

with recourse" business model, the parties require the con- a stock exchange. Since the creation of the new DBA entity 

vener to record the messages between the computers as well is the creation of a new party, the convener will create a new 

as all of the execution instructions. Any of the parties to the conversation certificate and distribute it to the parties in the 

business deal can have recourse to the message log because 5 manner described above. 

each of the parties can decrypt messages in the message log The adoption of conversation certificates and introduction 

using the new public key contained in the conversation certificates as described above as a basic means of authon- 

certificate. The parties to the business deal are, within the ^^^^n by exchanges and other participants in the securities 

context of the business arrangement, highly motivate to industry would enable the construcuon of new systems that 

^ . . . uv ^ fu /.,ir.'A^ «,,t.« would enable the construction of new systems that would 

prevent sharing the new pubhc key with outside parties. lO „ ^ ^^^^ broader range of business functions 

however. An "externa registration buswess model is simi- ^^^^^ ^ ^^^^^^^ 

lar to the "reflexive club with recourse model except that ^i^tionships will be supportable than is now the case, 

the parties to the business deal are free to share the new participants in such relationships to 

public-key with ouLside parties. constnicU at their own initiative and convenience, the sys- 

At the end of the conversation, one of the computers ^5 constructs that represent those relationships is particu- 
notifies the convener that the conversation is finished (step larly powerful. It allows such relationships to be made 
102), and the convener records a "done" notice in the without any prior systems arrangements between the par- 
message log, encrypted with the new private key (step 104). ticipants (the only prior arrangement required is a commu- 
After a predetermined period of time has elapsed, the nications link between the participants, but that could be by 
convener destroys the private key (step 106). This makes it 20 way of any public network). The arrangements can be made 
impossible to alter the log entry; yet the parties to whom the before it is known what transactions will be performed by 
conversation certificate was distributed (and outside parties the relationship. For example, a partnership could be set up 
if an "external registration" business model is followed) may to make investments of certain characteristics; decisions 
read the message log by decrypting the messages using the about whether the transactions creating the investments 
new pubUc key contained in the conversaUon certificate 25 should be made at one stock exchange or another, or on a 
(step 108). The DBA name or names can be anonymous, commodities exchange, or on some combination of 
thereby obscuring the actual parties to the business deal, exchanges, can be deferred untU later, 
consistent with ordinary business practice. TTie core value of «»"pl«. » representative of an institutional money 
the message log is that it provides recourse to the record of •""□ager invites representative of three brokerages to meet 
the facts of the business deal, even though the DBA is 30 hm, in negotiating a room at a stock exchange fac,hty_The 
anonymous and the exact nahire of the business deal is r°°°J '^^.^ '^f'^^l ^fSJ' 
lectronicall confidential authorities into readers embedded in the desk in the room. 
^ ^ . . t J Crypto-secure channels to each of the participants* home 

Should recourse ever be required, the log could be opened ^ ^^^^^ automaticaUy constrticted when the smart cards 

by any party holdmg the public key of the original conver- ^^^^ presented. The screens in the room light up to allow the 

sation certificate and then, if a portion of that log is found to participants to construct a conversation certificate to facili- 

be super^ncrypted, the parties who hold the additional keys ^^^^ ^^^^ ^^^^ ^^^^y manager describes a sensitive 

could be persuaded (perhaps by court order) to open their ^^^j ^^^^^ unwinding a large, complex position, 

sub-conversations usmg those keys. cstabUshing a new one within certain parameters which 

Occasionally it will be necessary to add or delete a party ^^e based, in part, on the effect the unwinding will have on 

to a conversation that is already under way. Upon receiving tj^g market. The participants 1) grant each other limited 

an instruction from one of the computers involved in the rights to share certain decision support systems and related 

business deal to add or delete a party, the convener will information; 2) grant the team the right to "take" the 

create a new conversation certificate and distribute it to the securities being sold from the money manager's inventory; 

new set of parties The convener will record, as the final entry 3^ g^.^^^ j^e team the right to "receive" the payments for sold 

in a first message log, a link to a new message log and will securities; 4) grant the team the right to use the "received" 

record, as the first entry in the new message log, a link to the payments to purchase certain other securities; 5) grant the 

first message log, as described above in connection with team the right to place received securities into the account of 

FIGS. 3 and 4. the money manager; 6) grant the team the right to make 

The parties to the business deal may communicate using 50 trades using the securities and received funds described 

smart cards in personal digital assistants (PDAs), which above; 7) grant each broker member the right to initiate the 

might be wireless. If wireless or other eavesdroppable trades described above on behalf of the team, in accordance 

technology is used, the smart cards would encrypt and with the rights granted to the team, provided at least one 

decrypt message transmissions using the new public key in other team member (broker or money manager) gives con- 

the conversation certificate and any super-encryption desired 55 sent either prior to or contemporaneously with the trade; 8) 

by the parties to the business deal. For example, execution create an agent process to act on behalf of the team to 

instructions to specialists on the trading floor could be accumulate results of the teams activities and notify the team 

encrypted with a sender's private key and a recipient's members of the various running totals (the process gets a 

public key to ensure security. principal identity and is recorded as a member of the team); 

During the course of a conversation, and especially when 60 9) set the expiration of the rights granted to be close of 

a party to the conversation is added or deleted, the parties business, day after tomorrow, or at any eariier time the 

may request that the convener create an introduction cer- money manager may determine. 

tificate for a new DBA entity. The convener creates and In addition, the money manager grants two of the broker 

distributes the introduction certificate in the manner members prior authority to initiate trades up to $1,000,000 

described above, and only the parties to the business deal 65 in value. The third broker is given prior authority to initiate 

need to know the details of the new arrangement. The trades up to $2,000,000 in any security, or 250,000 shares of 

convener's reputation will serve to introduce the new DBA XYZ common. 
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A new conversation certificate is created to record the 
activities of the team. Cross references are entered into each 
of the certificates, and the certificate that created the team is 
sealed, and registered with the stock exchange in accordance 
with its rules. ^ 

Two of the team members leave the room and head to the 
trading floor, taking their smart-card certifying authorities 
with them. As they leave the room, they insert their smart- 
card certifying authorities into their PDAs or HHDs and, as lo 
they enter the regulated trading area, they log onto the floor 
and signal their readiness to trade. 

While the broker-members on the floor are lining up 
trading opportunities for the various securities in the 
unwinding position, the other two team members are work- 
ing the terminals in the negotiating room looking for oppor- 
tunities (on and off" the exchange) to establish the new 
position and to appropriately make the transition. They have 
access to some of the system resources of the team members 20 
who left the room, because those rights were granted them 
in the compact. 

As the floor members make trades on behalf of the team 
their PDAs or HHDs relay the results back to the team's 
agent process, which records the activity in the open con- 
versation certificate, and notifies all the team members of the 
amount of cash that has been accumulated by the team. The 
cash, of course, is really in the form of bookkeeping entries, 
probably in the trading accounts of the team members. The 
authority-relationship created by the team will allow the 
team to correctly allocate the results of the trading. In this 
scenario, all the results will eventually be returned lo the 
money manager's accounts. 

The money manager issues the credentials of the team to 35 
make a purchase of foreign currency contracts in Chicago, 
in anticipation of eventually taking a foreign equity position 
as part of the new position. Whether the money manager's 
identity needs lo be revealed, or whether the team's identity 
is sufiScient is at the discretion of the rules committee of the 40 
commodities exchange. 

There have been described novel and improved apparatus 
and techniques for certifying authorizations in computer 
networks. It is evident that those skilled in the art may now 
make numerous uses and modifications of and departures 
from the specific embodiments described herein without 
departing from the inventive concept. 
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NOTE: The following is a digest of draft-iet-pkix-ipki 
parti -01. txt and draft-ietf-pkix-ipki-partl-02.txt drafts. 

1. Background X.509 Certificates 

The X.509 v3 certificate Basic syntax follows. For sig- 
nature calculation, the certificate is ASN.IDER encoded. 65 
ASN.IDER encoding is a tag, length, value encoding system 
for each element. 



Certificate : SIGNED { SEQUENCE { 

version [0] Version DEFAULT vl, 

scrialNumber CeitificatcScrialNumber, 
signature AJgorithmldcntifier, 
issuer Name, 
validily Validity, 
subject Name, 
subjectPublicKcylnfo Subject PublicKcylnfo, 
issuerUniquelD [l] IMPLICIT Uniqucldentifier OPTIONAL, 

- If present, version must be v2 or v3 
subjectUniquelD [2] IMPLICIT Uniqucldentifier OPTIONAL, 

" If present, version must be v2 or v3 
extensions [3] Extensions OPTIONAL 

-- If present, version must be v3 

Version ^ INTEGER { vl(0), v2(l), v3(2) } 

CertificateScrifllNumber : INTEGER 
Validity : :- SEQUENCE { 

notBefore UTCTune, 

notAfter UTCTune } 

Uniqucldentifier : := BIT STRING 
SubjectPublicKcylnfo : :« SEQUENCE { 

algorithm AlgorithmldentLAer, 

subjectPublicKey BIT STRING } 
extensions : :- SEQUENCE OF Extension 
Extension : > SEQUENCE { 

extnID OBJECT IDENTIFIER, 

critical BOOLEAN DEFAULT FALSE, 

extnV^lue OCTET STRING } 



The following items describe a use of the X.509 v3 certifi- 
cate for the Internet. 

Version: This field describes the version of the encoded 
certificate. When extensions are used, as expected in this 
profile, use X.509 version 3 (value is 2). If no extensions are 
present, but a Uniqueldentifier is present, use version 2 
(value is 1). If only basic fields are present, use version 1 (the 
value is absent). 

Implementations should be prepared to accept any version 
certificate. In particular, at a minimum, implementations 
should recognize version 3 certificates; determine whether 
any critical extensions are present; and accept certificates 
without critical extensions even if they don't recognize any 
extensions. A certificate with an unrecognized critical exten- 
sion must always be rejected. 

Serial Number: The serial number is an integer assigned 
by the CA to each certificate. It must be unique for each 
certificate issued by a CA (i.e., the issuer name and serial 
number identify a unique certificate). 

Signature: This field contains the algorithm identifier for 
the algorithm used to sign the certificate. 

Issuer Name: The issuer name (combined with the 
IssuerUniquelD, if present) provides a globally unique iden- 
tifier of the authority signing the certificate. 

Validity: This field indicates the dates on which the 
certificate becomes valid (notBefore) and on which the 
certificate ceases to be valid (notAfter). The UTCTime 
(Coordinated Universal Time) values included in this field 
shall be expressed in Greenwich Mean Time (Zulu) and 
include granularity to the minute, even though finer granu- 
larity can be expressed in the UTCHme format. That is, 
UTCTime should be expressed as YYMMDDHHMMZ. 

Subject Name: The purpose of the subject name 
(combined with the SubjectUniquelD, if present) is to pro- 
vide a unique identifier of the subject of the certificate. 

Subject Public Key Info: This field is used to carty the 
public key and identify the algorithm with which the key is 
used. 

Unique Identifiers: The subject and issuer unique identifier 
are present in the certificate to handle the possibility of reuse 
of subject and/or issuer names over time. 
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Certificate Extensions The extensions already defined by 
ANSI X9 and ISO for X.509 v3 certificates provide methods 
for associating additional attributes with users or public keys 
and for managing the certification hierarchy. The X.509 v3 
certificate format also allows communities to define private 
extensions to carry information unique to those communi- 
ties. Each extension in a certificate may be designated as 
critical or non-critical. A certificate using system (an appli- 
cation validating a certificate) must reject the certificate if it 
encounters a critical extension it does not recognize. Anon- 
critical extension may be ignored if it is not recognized. The 
following presents recommended extensions used within 
Internet certificates and standard locations for information. 
Communities may elect to use additional extensions; 
however, caution should be exercised in adopting any criti- 
cal extensions in certificates which might be used in a 
general context. 

2.0 X.509 V3 Certificate Extensions 

2.1 Standard Extensions 
2.1. IKey Attributes 

The keyAttributes extension contains information about 
the key itself including a unique key identifier, a key usage 
period (lifetime of the private key as opposed to the lifetime 
of the certificate), and an intended key usage. The Internet 
certificate should use the keyAttributes extension and con- 
tain a key identifier and private key validity to aid in system 
management. The key usage field in this extension is 
intended to be advisory (as contrasted with the key usage 
restriction extension which imposes mandatory restrictions). 
The key usage field in this extension should be used to 
differentiate certificates containing public keys for validat- 
ing CA certificate signatures, for validating CA CRL 
signatures, and validating signatures on on-line transactions. 
However, the nonrepudiation and dataEnciphennent values 
should not be used. Where a reference to a public key 
identifier is needed (as with an Authority Key ID) and is not 
included in an attribute in the associated certificate, an 
SHA-1 hash of the public key shall be used. 

The GeneralizedTime values included in this field shall be 
expressed in Greenwich Mean Time (Zulu) and include 
granularity to the minute, even though finer granularity can 
be expressed in the GenerahzedTime format. That is, Gen- 
eralizedTime should be expressed as YYYYMMDDH- 
HMMZ. 

I mple mentors are warned that no DER is defined for 
GeneralizedTime, thus transformation between local time 
representations and the DER transfer syntax must be per- 
formed carefully when computing the hash value for a 
certificate signature. For example, a GeneralizedTime value 
which includes explict, zero values for seconds will not 
produce the same hash value as one in which the seconds are 
omitted. Generalized'Hrne expresses the using four digits. 
Remember that UTCTime represents the value of a year 
modulo 100, with no indication of century. 



KeyAttributes ::= SEQUENCE { 

kcyldentmcr Keyldentifier OPTIONAL, 

intcodedKcyUsage KcyUsage OPTIONAL, 

privateKeyUsagcPeriod PrivateKcy\^Udity OPTIONAL } 

Keyldentifier ::- OCTET STRING 

PrivateKfiyValidity SEQUENCE { 4 

notBefore [0] Generaiizcdrimc OPTIONAL, 

notAfier [1] GeneralizedTime OPTIONAL } 

KcyUsage ::- BIT STRING { 

digitalSignaturc (0), 
oonRepudiation (1), 
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keyEnciphcnncnt 


(2), 


dataEnciphcrmcnt 


(3), 


key Agreement 


(4), 


kcyCcrtSign 


(5). 


offUneCRLSign 


(6)} 
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2.1.2 Subject Alternative Name 

The subject alternative names extension allows additional 
identities to be bound to the subject of the certificate. 
Defined options* include an rfc822 name (electronic mail 
address), a DNS name, an IP address, and a URI. Other 
options exist, including completely local definitions. Mul- 
tiple instances of a name and multiple name forms may be 
included. Whenever such identities are to be bound into a 
certificate, the subject alternative name (or issuer alternative 
name) extension shall be used. (Note: a form of such an 
identifier may also be present in the subject distinguished 
name; however, the alternative name extension is the pre- 
ferred location for finding such information.) Further, if the 
only subject identity included in the certificate is an alter- 
native name form (e.g., an electronic mail address), then the 
subject distinguished name should be empty (an empty 
sequence), the subjectAltName extension should be used, 
and the subjectAltName extension must be marked critical. 
Alternative names may be constrained in the same manner 
as subject'M distinguished names using the name con- 
straints extension. 



AllNames :> SEQUENCE OF GeneralName 
GeneralName :> CHOICE { 

olherName [0] INSTANCE OF OTHER-NAME, 

rfc822Name [1] IA5String, 

dNSName [2] lASString, 

x400Addrcss [3] ORAddrcss, 

directoryNamc [4] Name, 

cdiPartyNamc [5] IA5 String, 

url [6] lASSlring, 

ipAddrcss [71 OCI'ET STRING ) 



2.1.3 Issuer Alternative Name 
As with 2.1.2, this extension is used to associate Interact 

style identities with the certificate issuer. If the only issuer 
identity included in the certificate is an alternative name 
form (e.g., an electronic mail address), then the issuer 
distinguished name should be empty (an empty sequence), 
the issuer AltName extension should be used, and the issu- 
erAltName extension must be marked critical. 

2.1.4 Basic Constraints 

The basicConstraints extension identifies whether the 
55 subject of the certificate is a CA or an end user In addition, 
this field can limit the authority of a subject CA in terms of 
the certificates it can issue. Discussion of certification path 
restriction is covered elsewhere in this draft. The subject 
type field should be present in all Internet certificates. 

60 



45 



50 



basicConstraints ;:= SEQUENCE { 
subj eciT^'pe Subj ectl^Tie, 
pathUnConsiraint nSTTEGER OPTIONAL, 
65 penniUedSubtrees [0] SEQUENCE OF GeneralName OPTIONAL, 
excludedSubtiees [1] SEQUENCE OF GeneralName OPTIONAL } 
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Subjccfrype 
cA 

cndtntity 



::= BIT STFRING { 
(0), 

0)} 



2.1.5 Name Conslrainls 

The name constraints extension provides permitted and 
excluded subtrees that place restrictions on names that may 
be included within a certificate issued by a given CA. 
Restrictions may apply to the subject distringuished name or 
subject alternative names. Any name matching a restriction 
in the excluded subtrees field is invalid regardless of infor- 
mation appearing in the permitted subtrees. Restrictions for 
the rfc822, dNSName, and uri name forms are all expressed 15 
in terms of strings with wild card matching. An is the 
wildcard character. The minimum and maximum fields in 
general subtree are not used for these name forms. For uris 
and rfc822 names, the restriction applies to the host part of 
the name. Examples would" be foo.bar.com; www* .bar.com; 20 
*. xyz.com. 

2.1.6 Policy Constraints 

The certificatePolicies extension contains one or more 
object identifiers (OlDs). Each OID indicates the policy 
under which the certificate has been issued. This profile 25 
expects that a simple OID will be present in each PolicyEle- 
mentlnfo. The qualifier within the PolicyElementlnfo should 
be absent. Implementations processing certificate policy 
fields are expected to have lists of those policies which they 
will accept. The implementations compare the policy 3Q 
identifier<s) in the certificate to that list. This field provides 
information to be used at the discretion of a relying party. In 
contrast, the policy identifier(s) in the keyUsageRestriclion 
is a mandate by the issuer that a certificate be used only in 
particular environments. 35 



CertificatePolicies SEQUENCE OF Pol icy Information 
Policylnformation ::= SEQUENCE OF PolicyElementlnfo 
PolicyElementlnfo ::= SEQUENCE { 

policyElementld OBJECT IDENTIFIER, 

qualifier ANY DEFINED BY policyElementld OPTIONAL } 



2.1.7 Authority Key Identifier 

The authority key identifier extension provides a means of 45 
identifying the particular public key used to sign a certifi- 
cate. The identification can be based on either the key 



identifier (from the key Attributes extension) or on the issuer 
name and serial number. The key identifier method is 
recommended in this profile. This extension would be used 
where an issuer has multiple signing keys (either due to 
multiple concurrent key pairs or due to changeover). In 
general, this extension should be included in certificates- If 
the issuer name/serial number approach is used, both the 
ccrtlssuer and certSerialNumber fields must be present. 



authorityKcyld ::- SEQUENCE { 

keyldentifier [0] Keyldenlifier OPTIONAL, 
certlssuer [l] Name OPTIONAL, 

certSerialNumber [2] CcrtificateSe rial Number OPTIONAL } 



2.1.8 Subject Directory Attributes 

The DAM provides an extension for subject directory 
attributes, lliis extension may hold any information about 
the subject where that information has a defined X.500 
Directory attribute. This extension is not recommended as an 
essential part of this profile but may be used in local 
environments. This extension is always non-critical. 

subjectDirectory Attributes : := SEQUENCE OF Attribute 
2.1 User Defined Extensions 

see RSA user defined extensions and extension handlers 
3.0 CRL Extensions 

The X.509 v2 CRL syntax is as follows. For signature 
calculation, the data that is to be signed is ASN.l DER 
encoded. ASN.l DER encoding is a tag, length, value 
encoding system for each element. 

The extensions defined by ANSI X9 and ISO for X.509 v2 
CRLs [X.509- AM] [X9. 55] provide methods for associating 
additional attributes with CRLs. The X.509 v2 CRL fonnat 
also allows communities to define private extensions to 
carry information unique to those communities. Each exten- 
sion in a CRL may be designated as critical or non-critical. 
A CRL validation must fail if it encounters an critical 
extension which it does not know how to process. However, 
an unrecognized non-critical extension may be ignored. The 
following presents those extensions used within Internet 
CRLs. Communities may elect to use additional extensions; 
however, caution should be exercised in adopting any criti- 
cal extensions in CRLs which might be used in a general 
context. 



CertificateList : > SEQUENCE { 
tbsCertList TBSCeriList, 
signature Algorithm Algorithmldentifier, 
signature BIT STRING } 

TBSCcrtli.st : := SEQUENCE { 

version Version OPTIONAL, 

- if present, must be v2 
Algorithmldentifier, 
Name, 
UTCTimc, 
UTCTimc, 

SEQUENCE OF SEQUENCE 
CertificateSerifllNumber, 
UTCnmc, 

Extensions OPTIONAL 
[0] Extensions OPTIONAL 
vl(0),v2(l),v3C2) } 



signature 
issuer 
. thisUpdatc 
nextUpdatc 
revoked Certificates 
userCertificate 
revocationDate 
crl En try Extensions 
crl Extensions 
Version : INTEGER 
Algorithmldentifier : := 
algorithm 



{ 

SEQUENCE { 
OBJECT IDENTIFIER, 



} OPTIONAL, 
} 
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-continued 



ANY DEFINED BY algorithm OPTIONAL 
-- contains a value of the type 
-- registered for use with the 

- algorithm object identifier value 
CertificateSerialNumbcr : := INTEGER 

Extensions : ;« SEQUENCE OF Extension 
SEQUENCE { 

OBJECT IDENTIFIER, 
BOOLEAN DEFAULT FALSE. 
OCTET STRING } 

- contains a DER encoding of a value M 
-- of the type registered for use with M 

- the extnid object identifier value 



parameters 



Extension : :«> 
extnid 
critical 
extn Value 
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3.1 Standard Extensions 
3.1.1Rcason Code 

'Yhc reasonCode is a non-critical CRL entry extension that 
identifies the reason for the certificate revocation. CAs are 
strongly encouraged to include reason codes in CRL entries; 
however, some reasonCode values are strictly prohibited. 
The reason code extension permits certificates to placed on 
hold or suspended. The processing associated with sus- 
pended certificates greatly complicates certificate validation, 
therefore the use of reasonCode values certificateliold (6), 
certHoldRelease (7), and removeFromCRL (8) shall not be 
used. Also, the reasonCode CRL entry extension should be 
absent instead of using the unspecified (0) reasonCode 
value. 



CRLReason :> ENUMERATED { 



unspecified 


(0). 


kcyCompromisc 


(1). 


caCompromisc 


(2). 


afi51iationChangcd 


(3), 


superseded 


(4), 


cessationOfOpe ration 


(5), 


certificatcHold 




certHoldRelease 


(7). 


removeFromCRL 


(8)} 
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3.1.2 Invalidity Date 

The invalidityDate is a non-critical CRL entry extension 
that provides the date on which it is known or suspected that 
the private key was compromised or that the certificate 
otherwise became invalid. This date may be earlier than the 
revocation date in the CRL entry, but it must be later than the 
issue date of the previously issued CRL. Remember that the 
revocation date in the CRL entry specifies the date that the 
CA revoked the certificate. Whenever this information is 
available, CAs are strongly encouraged to share it with CRL 
users. 

InvalidityDate : General izedTime^M 

3.1.3 Authority Key Identifier 

The authorityKeyldentifier is a non-critical CRL exten- 
sion that identifies the CA's key used to sign the CRL. This 
extension is useful when a CA uses more than one key; it 
allows distinct keys differentiated (e.g., as key updating 
occurs). The key may be identified by an explicit key 
identifier, by identification of a certificate for the key (giving 
certificate issuer and certificate serial number), or both. If 
Loth are used then the CA issuer shall ensure that all three 
fields are consistent. 



50 



55 



AuthorityKeyld :> SEQUENCE { 

kcyldentifier [0] Keyldentifier OPTIONAL, 
ccrtlssucr [2] Name OPTIONAL, 

ccrtScrialNumbcr [2] CertificateSerialNumbcr OPTIONAL } 

- ccrtlssucr and ccrtScrialNumbcr constitute a logical pair, 

- and if cither is present both must be present. Either this 

- pair or the keyldentifier field or all shall be present 



3.1.4 CRL Number 

The cRLNumber is a non-critical CRL extension which 
conveys a monotonically increacing sequence number for 
each CRL issued by a given CA through a specific CAX.500 
Directory entry or CRL distribution point. This extension 
allows users to easily determine when a particular CRL 
superceeds another CRL- CAs conforming to this profile 
shall include this CRL. 

CRLNumber : INTEGER 

3.1.5 Issuing Distribution Point 

The issuingDistributionPoint is a critical CRL extension 
that identifiers the CRL dislribution point for this particular 
CRL, and it indicates whether the CRL covers revocation for 
end entity certificates only, CA certificates only, or a liritied 
set of reason codes. Support for CRL distribution points is 
strongly encouraged. The use of certificateHold is strictly 
prohibited in this profile. 

Only the following reason codes may be used in conjunc- 
tion with this profile. The use of keyCompromise (1) shall be 
used to indicate compromise or suspected compromise. The 
use of afiiliationChanged (3), superseded (4), or cessationO- 
fOperation (5)shall be used to indicate routine compromise. 

The CRL is signed by the CA*s key. CRL Dislribution 
Points do not have their own key pairs. If the CRL is stored 
in the X.500 Directory, it is stored entry corresponding to the 
CRL distribution point, which may be different that the 
directory entry of the CA. 

CRL distribution points, if used, should be partitioned the 
CRL on the basis of compromise and routine revocation. 
That is, the revocations with reason code (1) shall appear in 
one distribution point, and the revocations with reason codes 
(3), (4). and (5) shall appear in another distribution point. 



DUtributionPoint SEQUENCE { 

distributionPoint Distribution PointName, 

reasons ReasonRags OPTIONAL } 

DistributionPoinlName ::= CHOICE { 
fullName [0] Name, 

nameRelaiiveToCA [1] Relative DistinguishedName, 

generalName 12] GeneralName } 



05/28/2004, EAST Version: 1.4.1 



us 6,192,131 Bl 



21 



-continued 



22 



GcncralName CHOICE { 

othcrNamc [0] INSTIANCl: OF OIHER-NAMI;, 

rfc822Namc ( 1 ] I A5St ring, 

dNSNamc [2] LA5Slring, 

3i400Address [3] ORAddrcss, 

dircctoryName [4] Name, 

cdiPartyName [5] lASSlring, 

unifonnResourceLocator [6] lASString } 



OTHER-NAME ::- TYPE-IDENTTFIER 



10 



3.L6 Delta CRL Indicator 

The dellaCRLIndicalor is a critical CRL extension that 
identifies a delta -CRL. The use of delta -CRLs can signifi- 
cantly improve processing time for applications which store 
revocation information in a format other than the CRLstruc- 
ture. This allows changes to be added to the local database 
while ignoring unchanged information that is already in the 
local databse. CAs are shall always issue a complete CRL 
when a delta-CRL is issued. 

The value of BaseCRLNumber identifies the CRL number 
of the base CRL that was used as the starting point in the 
generation of this delta- CRL, The delta-CRL contains the 
changes between the base CRL and the current CRL issued 
along with the delta-CRL. It is the decision of a CA as to 
whether to provide delta -CRI^s. Again, a delta-CRL shall not 
be issued without a corresponding CRL. Tlie value of 
CRLNumber for both the delta-CRL and the corresponding 
CRL shall be identical.' 

A CRL user constructing a locally held CRL from delta- 
CRLs shall consider the constructed CRL incomplete and 
unusable if the CRLNumber of the received delta-CRL is 
more that one greater that the CRLnumber of the delta-CRL 
last processed. 
3.2 User Defined Extensions 

TBD 
References 
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What is claimed is: 

L A system for creating a log of a conversation, com- 
prising: 

an arbiter computer; and 

a plurality of conversation computers; 

the arbiter computer and the conversation computers 
being interconnected by a computer network; 

the arbiter computer being programmed to create a public 
key pair comprising a new public key and a new private 
key, to cause the new public key to be transmitted to the 
conversation computers, to use the new private key to 
encrypt messages transmitted by at least some of the 
conversation computers during a conversation among 
the conversation computers, and to store the encrypted 
messages in a message log; 

the conversation computers being programmed to receive 
the public key, to transmit messages during the 
conversation, and to cause messages in the message log 
to be decrypted using the new public key. 

2. The system of claim 1 wherein the arbiter computer is 
programmed to decrypt the public key certificate that iden- 
tify the user of the conversation computer, using a public key 
of a certifying authority that generated the certificate iden- 
tifying the user of the conversation computer. 

3. llie system of claim 1 wherein the arbiter computer is 
programmed to create a conversation certificate that certifies 
that a holder of the conversation certificate is authorized to 
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read messages in a message log referred to in the conver- 
sation certificate, the conversation certificate comprising the 
new public key. 

4. The system of claim 3 wherein the arbiter computer is 
programmed to encrypt the conversation certificate using the 
public key of a user of one of the conversation computers. 

5. The system of claim 1 wherein the messages U"ansmit- 
tcd by the conversation computers comprise messages trans- 
mitted to parties other than the conversation computers. 

6. The system of claim 1 wherein the messages transmit- 
ted by the conversation computers comprise messages trans- 
mitted between conversation computers. 

7. The system of claim 1 wherein at least one of the 
conversation computers is programmed to notify the arbiter 
computer that a conversation among the conversation com- 
puters is completed. 

8. The system of claim 7 wherein the arbiter computer is 
programmed to place a notice in the message log indicating 
that the conversation is finished. 

9. The system of claim 1 wherein the arbiter computer is 
programmed to destroy the private key after the conversa- 
tion is completed. 

10. The system of claim 1 wherein at least one of the 
conversation computers is programmed to notify the arbiter 
computer of a change in parties to the conversation. 

11. The system of claim 1 wherein, in response to noti- 
fication of the change in parties, the arbiter computer is 
programmed to create another public key pair comprising a 
new public key and a new private key, to cause the new 
public key to be transmitted to the conversation computers, 
to use the new private key to encrypt messages transmitted 
by at least some of the conversation computers during a 
conversation among the conversation computers, and to 
store the encrypted messages in another message log. 

12. A method for creating a log of a conversation in a 
computer network comprising an arbiter computer and a 
plurality of conversation computers, comprising the steps of: 

creating, at the arbiter computer, a public key pair com- 
prising a new public key and a new private key; 

causing the new public key to be transmitted to the 
conversation computers; 

transmitting messages during a conversation among the 
conversation computers; 

using the new private key at the arbiter computer to 
encrypt messages transmitted by at least some of the 
conversation computers during the conversation 

storing the encrypted messages in a message log; 

causing messages in the message log to be decrypted 
using the new public key transmitted to at least one of 
the conversation computers. 

13. A system for creating a log of a conversation, com- 
prising: 

an arbiter computer; and 

a plurality of conversation computers, programmed to 
transmit to the arbiter computer a public key certificate 
that identifies a user of the conversation computer and 
a public key of the user; 

the arbiter a)mputer and the conversation computers 
being interconnected by a computer network; 

the arbiter computer being programmed to create a pubhc 
key pair comprising a new public key and a new private 
key, to cause the new public key to be transmitted to the 
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conversation computers, to use the new private key to the conversation coniputers being programmed to receive 

encrypt messages transmitted by at least some of the the public key, to transmit messages during the con- 

'^^ . ^ , . . versation and to cause messages m the message log to 

conversauon computers during a conversation among ^ decrypted using the new public key. 
the conversation computers, and to store the encrypted 

messages in a message log; ♦ ♦ ♦ ♦ ♦ 
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